Integrated System Design
Posted 11/06/01, 05:27:52 PM EDT

Analog field program
Lattice Semiconductor (Hillsboro, Ore.) recently unveiled an in-system reconfigurable analog front-end chip, the isp PAC-30, intended for signal conditioning, laser control and other jobs typically performed by instrumentation amps and simple filters. The device is the latest member in a family of field-programmable analog chips that also includes, for example, a fifth-order analog filter.

It doesn't take a lot of reflection to see the advantages-both functional and logistical-to being able to field-configure a precision analog device. But according to director of mixed-signal products Hans Klein, it takes a considerable amount of planning to design one. There are less-than-obvious choices in creating a configurable array of parameterizable analog building blocks on a chip.

One of the first issues is deciding whether to use continuous-time or switched-capacitor techniques. Since switched-capacitor filters are constructed with fixed analog components and analog switches, they might seem the obvious approach: Just add more switches to let the user switch in any of a selection of component values. That's fine from the chip designer's point of view, Klein says, but problematic for the user. Switched-capacitor circuits have important limitations compared with continuous-time circuits, and they have to be modeled and used with considerable care. So Lattice chose to do continuous-time designs.

That raised a number of problems for the design team. To start with, Lattice is a fabless company, and you don't just order up a precision analog process with excellent programmable switches from the nearest foundry. Fortunately Lattice, which has been in the E2 programmable logic business for years, has always maintained its own process development and modeling group. That was essential to the design, according to Klein.

The next challenge was circuit design. The obvious approach won't work, because it leaves the analog switches used for selecting component values in the signal path, where the impedance of the switch becomes a circuit parameter. No matter how good your switches are, that will be a problem. For instance, the on-resistance of the switches will behave differently with temperature than the values of fixed resistors on the same substrate. So circuit designs had to be developed that kept the switches out of the signal path.

Verification and test were similar challenges. Suffice it to say that those little configurable analog parts represent a considerable intellectual investment at all levels: architectural planning, circuit design and process development.

Net security crack
One of the unintended consequences of the breakup of Digital Equipment Corp. was the dissolution of one of the most skilled custom digital design teams in the world. The Alpha processor developers had made such a habit of showing up at the Hot Chips or ISSCC meetings and reporting another record operating frequency that it was becoming a tradition. A lot of designers assumed that Digital had kept Alpha chips ahead of the rest of the world by performing superhuman feats on the process side of the equation. But it looks like that was not the whole story.

Now that individual groups from the Alpha program are working in other fabless places, it has become apparent that a lot of the expertise was in methodology and circuit design. One example comes from Cavium Networks (San Jose, Calif.), a startup that is just introducing a programmable encryption engine for IPsec and Secure Socket Protocol applications.

The problem with using a programmable approach on wire-speed encryption, of course, is performance. But that is a very familiar problem to Cavium's design team. Each of the Digital alums has done at least two microprocessors.

And the group brings something of the old Alpha methodology to SoC design. Perhaps surprisingly, the MPU skills fit very well in the new environment. Encryption algorithms are highly compute-intensive, and a programmable engine is an exercise in making a fast arithmetic processor. The custom circuit design skills of the team really shone here, according to vice president of hardware design Anil Jain, producing close to an order of magnitude improvement in multiplier speed over the baseline design.

But some of the methodology lessons from the Alpha days were equally important. Chief among these was attention to detail in clock and power distribution. Like Alpha, the Cavium design uses a grid, rather than a tree structure, for clock distribution. The grid was developed at the floor-plan stage, well before the details of the circuitry it would be driving.

Just as important as the metal, according to Jain, was the placement of the decoupling capacitors. He warned that you don't just drop decoupling in as an afterthought when your clock network is subject to transients in the hundreds of picoseconds. The decoupling was built into the drivers, which in turn were located in the grid from the beginning. The approach kept the final clock skew across the entire die under 50 ps.

That achievement could have been undermined by the need for conditional clocking. The design needed to conserve power everywhere possible. But Jain's team confined the clock switching to the functional block level, so that possible skews induced by clock switches were confined to functional boundaries. That significantly eased the verification problem.

Similar attention was necessary for power distribution. Rather than insert power and ground during placement or routing, the power grid also went into the floor plan. Mechanical issues, such as just how to get supply current down through the eight-layer metal stack, had to be thought out in advance. Once that was done, there were extensive I-R calculations, still at the floor-planning level, to make sure the power grid was adequate.

Such disciplines evolved from hard necessity in the Alpha processor design days. But in Cavium's experience, they are equally applicable to performance-critical systems-on-chip. The only difference is that the SoC may have fewer blocks that absolutely require the ministrations of the custom cell folks. The methodology is a benefit throughout.

VSIA at crossroads
The Virtual Socket Interface Alliance set itself some very aggressive goals at the outset: to produce a set of standards that would ensure drop-in compatibility for silicon intellectual property in SoC designs. This charter covered a whole range of compatibility issues, from design formats to verification suites to bus interfaces.

A lot of observers looked at the goal, assumed that the volunteer industry group would attempt to establish a single standard for, say, bus interfaces, and predicted rapid failure.

But the VSIA working groups took another path, more realistic if less definitive. They declined to prescribe a single format for each facet of IP reuse, avoiding the issue of creating winners and losers among the vendors that had already established competing formats. Instead, they codified a number of competing proposals on each issue, creating something of a "Chinese menu."

The result doesn't guarantee that you can do a Web search and come up with IP blocks that are already compatible with your existing design flow. But it does bring some sort of standards to the notion of an IP product. Thanks to VSIA, IP is no longer just a pile of Verilog code.

Having done that, the question is what to do next. VSIA could evolve into a maintenance organization, watching over and gradually refining its specifications.

Or it could take on a new challenge. And the executive committee thinks it has found just the challenge: software.

Obviously, the software content of systems based on SoC designs is enormous and growing. Less obviously, perhaps, functional blocks of software have very similar characteristics to blocks of hardware IP. They have models at various levels of abstraction, structural information, verification and documentation needs. The design team works with software blocks in parallel with its hardware efforts.

The big difference, from the point of view of VSIA, is that hardware-dependent software-the stuff most closely linked to the chip design-lags far behind hardware IP in reusability.

In short, hardware-dependent software has the same issues now that hardware IP had when the VSIA was founded.

There are, of course, big differences as well. Not the least of them is that, while chip designers do get involved in software development, there is a huge cultural divide between chip designers and programmers.

Nonetheless, VSIA is going to ask its membership if software may not be the next challenge it should undertake.

http://www.isdmag.com

© 2001 CMP Media LLC.
11/1/01, Issue # 13149, page 10.